refactor(core-web): TS strict mode across 30 projects — template-builder, edit-ema-ui, block-editor, ui, data-access, sdk-*, portlets - #36957

Add the standard per-project strict flags to `libs/sdk/create-app/tsconfig.json`,
following the pattern established in #36879 (dotcms-models). `tsconfig.base.json`
is left at `strict: false`.

Two errors surfaced, both from flags beyond plain `strict`:

- `src/index.ts:393` — `process.env.DEBUG` needs bracket access under
  `noPropertyAccessFromIndexSignature` (TS4111). It is the only `process.env.*`
  dot access in the project.
- `src/utils/index.ts:41` — `fetchWithRetry` tripped `noImplicitReturns`
  (TS7030). The loop returns on success and throws on the last attempt, but with
  `retries < 1` the loop never runs and the function fell through returning
  `undefined`. Its only caller already guarded with `if (res && ...)`, so nothing
  broke in practice, but the signature was lying. Throwing after the loop closes
  the gap and narrows the return type.

No build or CI wiring needed. The `@nx/esbuild:esbuild` executor type-checks
before bundling — `skipTypeCheck` defaults to false and is not overridden — and
CI already builds this project via `nx run-many -t build` (`build-test` in
core-web/pom.xml). The same build runs in the SDK release pipeline
(`cicd_release-sdk.yml` → `nx run-many --projects='sdk-*'`), so the flags are
enforced on every release.

Verified: tsc clean on lib and spec; `nx run sdk-create-app:build/lint/test`
green; `nx affected -t build,lint` green; `node dist/libs/sdk/create-app/index.js
--help` still works. Negative test — reverting the DEBUG fix makes
`nx run sdk-create-app:build` fail with TS4111, confirming the gate is real.

Closes #35938

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Add the standard per-project strict flags to `libs/utils/tsconfig.json`,
following the pattern from #36879 (dotcms-models), and resolve the 32 errors
they surface across 3 files. `tsconfig.base.json` stays at `strict: false`.

The flags also propagate to `tsconfig.spec.json`, which surfaced 17 further
errors in the spec files (baseline was 0). Those are fixed here too rather
than left as a regression.

Notable changes:

- `EMPTY_FIELD` assigned `null` to 18 members that `DotCMSContentTypeField`
  declares non-nullable. Replaced with zero values of the declared types.
  Nothing compares those members to `null` strictly — consumers use falsy
  checks such as `isNewField`'s `!field.id` — so `''`, `0` and `false` behave
  identically at runtime.
- `clazz` has no zero value (`DotCMSClazz` is a union of concrete Java class
  names), so `EMPTY_FIELD` and `EMPTY_SYSTEM_FIELD` are now typed
  `Omit<DotCMSContentTypeField, 'clazz'>`. They are partial templates, not
  valid fields, and the type now says so. The derived `COLUMN_FIELD`,
  `ROW_FIELD` and `TAB_FIELD` already supply their own `clazz`.
- `getFieldsWithoutLayout` used a truthy `.filter()` that does not narrow the
  optional `row.columns`. Replaced with a type predicate, which clears the
  TS2532 and both TS2769 errors without a cast.
- `ellipsizeText` accepted `null`/`undefined` at runtime — its own guard and
  its tests document that — but declared `string` and `number`. Widened to
  match, with an explicit `limit == null` check so the later comparisons
  narrow.
- `fallbackErrorMessages` typed `{ [key: number]: string }`, mirroring the
  identical declaration already in `libs/data-access/.../dot-upload.service.ts`.
- `dot-utils.ts` uses bracket access for the six `DotCMSContentlet`
  index-signature reads in `getImageAssetUrl`.

No new `any`, `@ts-ignore`, or `@ts-expect-error`. The nine `as unknown as`
casts added are all in spec files, on inputs the tests deliberately pass as
invalid, matching the idiom those files already used.

Verified:
- `tsc -p libs/utils/tsconfig.lib.json --noEmit` — 0 errors (from 32)
- `tsc -p libs/utils/tsconfig.spec.json --noEmit` — 0 errors (from 17)
- `data-access` typecheck went from 68 errors to 36, zero new
- `utils-testing` unchanged at 1 pre-existing error (missing jasmine types)
- `dotcms-ui` typecheck clean apart from a pre-existing missing
  `dotcms-webcomponents/loader` dist
- `nx format:check` green

Note: `utils` has no `build` target and is tag-excluded from lint and test, so
nothing in CI verifies these flags — the same accepted trade-off as #35939.

Closes #35940

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…#35943)

`dot-contentlet-thumbnail.componentWillLoad` assigns a `||` chain to `renderImage`,
which is declared `boolean`. Adding `image?: string` to `DotContentletItem` made that
chain `string | boolean`: the read used to go through a bracket index on a property
the model did not declare, which yielded `any` and hid it. Coerced with `!!`, which is
how `renderImage` is used at the only place that reads it.

This has been failing since 5a56f8e. I claimed "build still passes" on that commit
and the three after it on the strength of a grep that matched `build finished` in the
output; a clean run reports `build failed` and exits non-zero. Verified here by exit
status instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Five repeated shapes swept across the field components, all the same mistake in
different clothes: a value whose falsy case must *omit* a JSX attribute, declared as
though it could only ever be present.

- 7 × `tabIndex={this.hint ? 0 : null}` and 2 × `selected={… ? true : null}`.
- 7 attribute helpers (`isDisabled`, `shouldBeDisabled`, `getDisabledAtt`,
  `getRequiredAttr`) declared `: boolean` while returning null. They exist precisely
  so the attribute is dropped rather than rendered `false`, which only
  `boolean | undefined` can say.
- 6 × `shouldShowErrorMessage` returning the message instead of a boolean.
- 4 × `getDotOptionsFromFieldValue(checkProp(…))`, coalesced like the assignments
  before them.
- `dotValidateDate` / `dotValidateTime` declared `: string`; both doc comments already
  said "otherwise null" and only the annotation disagreed.

Build verified by exit status.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Runtime-keyed maps, the shared date/error utils, and `dot-autocomplete`.

Four object literals were being indexed by values only known at runtime — a DOM tag
name, a content-type field type, an HTTP status, a `KeyboardEvent.key` — and every
call site already branched on the lookup missing (`process ? process(value) : value`,
`getErrorMessage(message) || fallbackErrorMessages[status]`). Each now declares the
index signature that says so, and the two double-lookup sites hoist to a local so the
narrowing survives.

`getId` called `slugify` on its own already-slugified result, which is a no-op and was
the only reason a nullable reached the second call. `isStringType` now takes `unknown`,
which is what a type check is for. `dotParseDate` coalesces both halves — the
validators return null for a string that is not a date, and `DotDateSlot` declares
plain strings, with empty being what every reader already treats as unset.

`@tarekraafat/autocomplete.js` ships no types; added a shim next to the existing
Angular/PrimeNG ones declaring just the constructor `dot-autocomplete` uses.

Its `getInputElement`/`getResultList` both return `querySelector` results and are
absent until the suggestion list has rendered — `clearList` already guarded for that
while three siblings did not. `enteredList` also read `attributes['hidden']`, which
`NamedNodeMap` does not support; `getNamedItem` does.

Build verified by exit status.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Two real bugs surfaced here, both from the same mechanism: a declaration that was
wrong, hiding a mistake underneath it.

`DotUploadService.uploadFile` passed `maxSize` as the **second** argument to
`uploadBinaryFile(data, progressCallBack?, maxSize?)`. So `maxFileLength` has never
reached the temp-file API and the progress callback was handed a string. A
wrong-position argument, not a design choice — both the local and the parameter are
named `maxSize`. In practice the client-side `file.size <= maxSize` check in
`dot-form` rejects oversize files first, which is why nobody noticed.

`DotAssetService.create` declared `Promise<DotCMSContentlet[] | DotHttpErrorResponse[]>`
but `throw`s its error array, so the error arm is never *resolved* — which is why every
consumer reads it from a `.catch`. Narrowed to what it actually returns. Its
per-request `.catch((e) => e)` still resolves a rejected fetch *as* its error, so
`res.json()` can throw and the consumer gets a `TypeError` instead of
`DotHttpErrorResponse[]`; noted in place, since that one is a behaviour fix.

Also removed a `debugger` statement that was shipping in
`dot-asset-drop-zone.createDotAsset`.

The rest: `dot-form.uploadFile` resolves null on both failure paths and its caller
already reads `tempFile && tempFile.id`; `getFieldsFromLayout` and
`pipedValuesToObject` now report the empty cases their guards were written for; and
`dot-card-view`'s two selection helpers accept the optional `value` prop they already
test with `value && typeof value === 'string'`.

Build verified by exit status.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…35943)

All six flags are now in `libs/dotcms-webcomponents/tsconfig.json`, which Stencil
reads, so they are enforced by `build`. 295 errors across 42 files down to 0.

## Two compilers, two answers

The last error only existed for one of them. This project is type-checked twice — by
the workspace's `tsc` (6.0.3) and by Stencil, which bundles its own 5.8.3 — and
TypeScript 6 re-declared `Node.textContent` as an asymmetric accessor
(`get(): string`, `set(value: string | null)`). So `keys[i].textContent.replace(...)`
in `dot-key-value` is clean under 6 and `Object is possibly 'null'` under 5.8. The
project read 0 on `tsc -p` while the Stencil build still failed.

Where two compilers check the same sources, the build is the gate. Recorded in
`core-web/CLAUDE.md` along with the exit-status lesson from the four commits I
mis-verified by grep.

## The last of the tail

- `flatpickr`'s `DateOption` is `Date | string | number`, so `maxDate: null` matched
  none of its three overloads — TypeScript reported the selector argument, which sent
  me looking in the wrong place. An absent key is how flatpickr means "no limit".
- `dot-card-contentlet.item` is the third prop declared optional while `render` reads
  through it unguarded (`contentlet.language`), after both thumbnail components.
- `dot-autocomplete`'s `@Event() selection` was declared `EventEmitter<string>` and is
  never emitted: the event comes from autocomplete.js on the inner input and bubbles,
  carrying the library's own `SelectionFeedback` — which is what
  `dot-tags.onSelectHandler` reads. The declaration only ever existed to type the
  `onSelection` prop, and now types it correctly.

`dotcms-webcomponents:test` still cannot run (Stencil supports Jest 27, the workspace
is on 29). That is pre-existing and unchanged; it is why the build is the only gate.

Closes #35943

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

)

`dot-experiments-configuration-store.ts` was 24 of the project's 93 lib errors and one
root cause: the state interface declared eight members non-nullable while the initial
state seeds `undefined`/`null` for five of them, and every derived observable declared
away the null its own body returns (`experiment.goals ? {…} : null` typed
`Observable<Goals>`).

Widening those cascaded outward, which is the point — the store is now at 0 and the
components that consume its view models report the nullability they were always
handed. Total went 93 → 81 with the store's 24 absorbed.

Things the widening surfaced, all of which the code already half-knew:

- `disableStartExperiment` read `experiment?.trafficProportion.variants.length` — the
  `?.` guards only the first hop, so a loaded-but-incomplete experiment still threw.
- `setStartLabel` destructures with a `{ scheduling: null }` fallback and then read
  `experiment.scheduling` anyway, going around it.
- The four step updaters spread `state.experiment` unguarded, which builds a partial
  `DotExperiment` from `{ ...undefined }`.
- `getMenuItems` gated every entry on `experiment?.status` except the two enterprise
  ones, which were visible without an experiment and would throw on click. It now
  returns no items when there is nothing to act on.
- `AllowedConditionOperatorsByTypeOfGoal` maps 2 of the goal types, so indexing it by
  `GOAL_TYPES` misses for the others — `Partial<Record<…>>` says so.

Also fixed `processExperimentConfigProps`, which is fed the store's `configProps`
before the route resolver has run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…35964)

Three mechanical clusters.

**21 × TS2564.** Angular fields populated in `ngOnInit` / a `@Watch` rather than the
constructor — `form`, `componentRef`, `scheduling`, `itemList`. Definite assignment,
which is what the framework contract already means here.

**`handleSidebar(status: StepStatus)` in four components.** Its body opens with
`if (status && status.isOpen && …)`, so it was written for an absent status all along;
only the parameter disagreed once the step observables started reporting their null.

**11 × TS7006 in the chart.js layer.** The options file and the HTML-legend plugin
never imported chart.js's own types, so every callback parameter was implicit any.
Typing them surfaced two real gaps the untyped version hid:

- `chart.options.plugins.legend.labels.generateLabels(chart)` — every hop of that
  chain is optional in chart.js's option types.
- `LegendItem.datasetIndex` is optional (a legend entry need not map to a dataset),
  and it was being passed straight to `setDatasetVisibility(index: number)`.

Also four `confirmationService.confirm({ target: event.target })`: PrimeNG's
`Confirmation.target` is a non-null `EventTarget` while `Event.target` is nullable,
and the property is optional — undefined just omits the anchor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

… jstat (#35964)

`dot-experiments-reports-store` repeats the configuration store's shape exactly: the
state is honestly `| null` but every projector's declaration was not. Fixing it
surfaced three things:

- `BayesianNoWinnerStatus.includes(results?.bayesianResult?.suggestedWinner)` — the
  winner is absent until the bayesian result arrives, and an absent one is not a
  winner, which is the `null` the status list already produced.
- `getPromotedVariant$` is a `find`, so it is `undefined` when nothing is promoted,
  never `null`.
- `dotMessageService.get(key, suggestedWinner?.variantDescription)` passed a possibly
  absent value into `...args: string[]`. Spread instead — the no-winner legends take
  no argument at all.

`dot-experiments-list-store` had the same two null-seeded state members and the same
`route.parent` chain as its sibling.

`Object.keys(DotExperimentStatus).forEach(key => DotExperimentStatus[key])` needed
`keyof typeof`: `Object.keys` erases to `string[]` even though every key came from
that enum.

The chart.js layer again: `LegendItem.fillStyle`/`fontColor` are `Color | undefined`
and were assigned straight to CSS style properties, and two tooltip callbacks did
arithmetic on `TooltipItem.label`, which is a string.

`jstat` ships no types and has no `@types` package; added a narrow shim declaring only
the beta distribution `dot-experiment.utils` uses.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

93 → 0 on `tsconfig.lib.json`. The spec side fell from 289 to 211 on its own, since
most of those errors were the production types leaking in.

Two real defects, both surfaced by a flag rather than by a test:

**`getVariantUrl`'s `finally` read an unassigned `url`.** The `try` parses an absolute
URL and the `catch` retries as relative; `finally` then called `url.toString()`. If the
catch block's own `new URL` throws too — a genuinely malformed path — `url` was never
assigned and the `finally` replaced the real failure with "url is undefined". Both
branches assign it, so returning after the try/catch says the same thing and lets a
real failure propagate.

**`checkIfExperimentDescriptionIsSaving` returned its `&&` chain**, so with no sidebar
step it yielded that falsy value rather than a boolean, while every consumer declares
`Observable<boolean>`.

The rest is one shape repeated: a value that is legitimately absent, declared as though
it never were.

- `getBayesianVariantResult` is a `find`, so a variant the bayesian run did not cover
  has no result — and `getConversionRateRage` / `getProbabilityToBeBest`, which consume
  it, each already carry a `noDataLabel` for precisely that case.
- The three step components declare their view model inline and had drifted from what
  the store publishes.
- `FormControl<number>(value, { nonNullable: true })` cannot take a null seed;
  `FormControl<string>('')` without `nonNullable` is a `FormControl<string | null>`.
- `AbstractControl.get()` reports a missing control at seven call sites.
- `_select` in `dot-experiment-options-item` is injected `{ optional: true }`, so it is
  null when the directive is used outside its host.
- `jstat` needed a shim; `LegendItem.fillStyle`/`fontColor` are `Color | undefined` and
  were assigned to CSS style properties.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Widen DotCMSWorkflowStatus.scheme to `DotCMSWorkflow | null` to match the
API, and fix the resulting strict-mode fallout across specs (non-null
assertions, typed generics, PrimeNG event casts, and a stale user mock
field).

…lied on a defect (#35964)

80 non-null assertions inserted from tsc's exact line/column, plus three test setups
that my `setScheduling`/`setTrafficAllocation`/`setTrafficProportion` guards broke — and
they are worth spelling out, because the guards are right and the tests were wrong.

Each of those updaters used to spread `state.experiment` unguarded, so with nothing
loaded `{ ...undefined, scheduling }` produced a *partial* `DotExperiment` carrying one
field and no `id`, `name` or `status`. Three tests patched the store without loading an
experiment first and asserted on the result, which only worked because of that. Every
sibling test in the same describe calls `loadExperiment` first, and so does the app —
these sidebars only open for a loaded experiment. Setup corrected; no assertion relaxed.

One more test-only fix: `mockProvider(DotExperimentsService)` auto-mocks `start` to
return undefined, and `startExperiment` pipes off the result — an unhandled rejection
fired after the assertion had already passed.

## Two method notes

My batch-narrowing script inserted `!` at the end of the surrounding member chain rather
than after the expression tsc names, producing `expect(x.$title()!!!!!!!!!)`. Reverted
and rewritten to key off the quoted name in the message and verify it sits at the
reported column. It refuses the "Object is possibly 'null'" form, where tsc points at
the start of the object expression and its extent is not recoverable from the text — the
remaining 26 of those are hand work.

While that was broken it also introduced a syntax error, and **a syntax error suppresses
every semantic diagnostic in the program**: the count read 4 when it was really 184. Any
`TS1xxx` in the output means the number after it is meaningless.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…35964)

`strict` is now on in `libs/portlets/dot-experiments/portlet/tsconfig.json`, joining the
five flags that were already there. Both configs read 0 with no CLI overrides, tests and
lint pass, and the nine strict consumers of the models this touched are unchanged.

The project also had **5 type errors before any flag was added** — it has only a `test`
target, and `test` does not type-check, so nothing had ever looked.

## The 104 spec errors

Mostly one shape: a Spectator `query`/`queryLast` result, or an `AbstractControl.get()`,
dereferenced without narrowing. `!` is the sanctioned idiom in specs — the rule is off
for `*.spec.ts` repo-wide — and the assertions are honest: a click on nothing, or a form
missing a control the component's own `initForm` built, is a test failure and not a case
to handle.

The rest were fixtures drifting from what the store now publishes: `experimentStatus`
and `promotedVariant` are `undefined` (an absent status, a `find` with no match), not
null; `menuItems` is `[]`; `pageSate` is absent until the parent route resolves. Three
observables that emit null before their data loads had their emission destructured in
the subscribe pattern, which cannot carry an assertion — those now destructure from an
asserted parameter.

Two casts document a deliberate out-of-contract input rather than hide one: an
error-path test passing null where the payload type wants a value, and a test building
an experiment without a `trafficAllocation` to exercise the gray indicator.

## A method correction

My by-site substitution pass over-applied twice before I got it right: first a broad
regex that added ~70 assertions to `spectator.query` assignments that were already fine,
then a `dispatchMouseEvent` pattern whose `[^)]*` stopped at the inner `byTestId(...)`
and wrote `!!!` inside it. Both reverted. The version that stuck only edits lines tsc
actually reported, and I checked the diff for `(!`, `!!` and `[!` before committing.

Closes #35964

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…35932)

`libs/portlets/edit-ema/portlet/tsconfig.lib.json` compiled a spec from
another library — `data-access`'s `dot-favorite-contenttype.service.spec.ts`
— as one of its own production sources. Under that config's `types: []`
there are no jest globals, so it read as 136 errors. It was added by
"Redesign Content Palette" (#33660, d018b4b), but the palette lives in
`edit-ema/ui`, so the entry landed on the wrong project and has never done
anything: nothing under `edit-ema/portlet` references `FavoriteContentType`,
and jest collects by rootDir, so its test target never saw the file either.
`data-access:test` still collects and runs it, as it always has.

The paired entry in `tsconfig.spec.json` is dead for the same reason, though
it cost nothing — that config sets `types: ["jest", "node"]`, so the spec
compiled clean there. Removed for consistency, not for a count.

`libs/dot-rules/tsconfig.lib.json` excluded `**/*.spec.ts`, which does not
match `Rule.it-spec.ts` — the glob needs the literal `.spec.ts`. So three
integration specs compiled as production sources: 32 errors, and 3 more from
`src/test-setup.ts`, which the exclude list missed because it still named
`src/test.ts`, a file that no longer exists.

    edit-ema/portlet  tsconfig.lib.json    188 → 52
    edit-ema/portlet  tsconfig.spec.json    22 → 22
    dot-rules         tsconfig.lib.json     35 → 0

Those are honest baselines now, not fixes: no source changed. dot-rules is
at 0 under its current config only because none of the six strict flags are
on yet — that is the next step.

Worth flagging separately: the three `.it-spec.ts` files are now checked by
nothing, which is the truthful state rather than a new gap. They import
`ReflectiveInjector`, which Angular has removed, so they cannot run as
written and have not for years — deleting them is a call for a follow-up.

Verified: dot-rules 12/12 tests, edit-ema/portlet 1397 passed / 5 skipped,
lint clean on both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…35957)

`rule-event.model.ts` had every payload field optional, which is why
`DotRuleEngineContainerComponent` alone accounted for 116 of the project's
276 strict-mode errors — 74 of them `Object is possibly 'undefined'` on
`event.payload.rule`, `.condition`, `.conditionGroup` and `.ruleAction`.

The optionality was not caution, it was a design collision. These events
bubble in two stages: an inner component emits the entity it owns, then
`DotRuleComponent` re-emits with the `rule` — and where the child cannot know
it, the `conditionGroup` — attached, and only then does the container see it.
One interface described both ends, so it fitted neither: the container
dereferenced fields the type said might be absent, while the inner emitters
needed `as ConditionActionEvent` casts to compile at all.

Split into `*EmitEvent` types for stage one and container-facing types for
stage two, each field required exactly where a handler reads it. Two things
that fell out of doing it:

- `DotRuleComponent` declared its incoming parameters as
  `{ type: string; payload: { value: string; index: number } }` for five
  handlers, dropping the `ruleAction` / `condition` the container goes on to
  dereference. `Object.assign` smuggled it back at runtime. Those handlers now
  take the real emit type and build the outgoing event explicitly, which also
  stops this component writing into an object its child still owns.
- `DotConditionGroupComponent` emitted `type` *inside* `payload`, where no
  handler reads it, and omitted the top-level `type` the interface has always
  required. That is what the two `as` casts were hiding. Moved to the top
  level; the container ignores `type` on both events, so nothing changes.

Also `export type` on the container's backward-compatibility re-export: with
`isolatedModules` on, re-exporting an interface without it is `TS1205`, which
was 4 of the spec config's errors. Nothing outside `dot-rules` imports these
types — only `DotRulesModule` — so the shim is inert either way.

    tsconfig.lib.json    276 → 180
    tsconfig.spec.json   286 → 186

Counts measured with the six flags passed on the CLI; they are not in
`tsconfig.json` yet. Tests 12/12 and lint clean.

Noted, not changed: the container's `onDeleteConditionGroup` is unreachable —
nothing binds it — as is `DotConditionGroupComponent`'s `deleteConditionGroup`
output, which has a different type again. `ParameterChangeEvent` and
`TypeChangeEvent` were declared in this file and never referenced anywhere;
they are gone with it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The `Object.assign(this, iRule)` construction idiom is why `Rule.ts`,
`ServerSideFieldModel.ts`, `input.model.ts` and `base.model.ts` carried 111 of
the project's strict-mode errors between them: every field was declared
non-nullable and populated by a copy the compiler cannot see through, from
interfaces whose fields are all optional.

Widened what is genuinely absent rather than asserting it away. `key` is
`string | null` on `BaseModel`, `ConditionGroupModel` and `RuleModel` —
`isPersisted()` is `this.key != null`, so an unsaved entity without a key is
the normal case, not an edge one. `name` on `RuleModel` likewise: `DEFAULT_RULE`
sets it to `null` outright. Where a field is filled by a known collaborator
immediately after construction (`_type` via the `type` setter, `_opt` by
`RuleService`'s type loader) it takes a definite-assignment `!` with a comment
naming who assigns it.

Six things this turned up that were not typing problems:

- `ServerSideFieldModel.isValid()` reached `paramDef.inputType['options'][value]`
  for any parameter named `comparison`. `options` is declared on
  `DropdownInputModel`, not on the base, so for a non-dropdown that read
  `undefined` and then indexed it — a `TypeError` inside a `.some()` callback,
  outside the surrounding try/catch. Comparison inputs are dropdowns in
  practice, which is the only reason it never fired. Now narrowed with
  `instanceof`.
- `loadActionTypes()` and `loadConditionTypes()` each had a cached branch
  returning `observableFrom(this._*TypesAry)`, which emits array *items* where
  the caller destructures an array. Both arrays were initialised to `[]` and
  never written to, so `.length` was always 0 and the branch was unreachable.
  Removed the branch and the two fields rather than fixing a type on dead code.
- `ActionModel.isValid()` and `ConditionModel.isValid()` returned nothing from
  their catch blocks — declared `boolean`, actually `undefined`. Callers read it
  as falsy either way; they now say `false`.
- `ServerSideFieldModel.isValid()` returned `this._type.key !== 'NoSelection'`
  ANDed with `this._type.key`, i.e. `string | boolean`.
- `InputDefinition.verify()` was declared `{ [key: string]: boolean }` and
  returns `ValidationErrors | null`. Its one caller tests `verify(value) == null`,
  so the passing case was the one the type could not express.
- `getPageIdFromUrl()` was declared `string` and has a `return null`.

Two dead declarations went with it: `i18nBaseKey` on `DropdownInputModel` and
`RestDropdownInputModel` (never assigned, never read — both call sites read it
off `ParameterDefinition`, where it is assigned) and `priority` on
`ServerSideTypeModel`. `ParameterDefinition`'s five fields became constructor
parameters so the class cannot exist half-filled; `fromJson` is still the only
way it is built.

    tsconfig.lib.json    180 → 111

Tests 12/12, lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Project 24 of 44 in the strict-mode rollout (#35932). All six flags were
absent from `libs/dot-rules/tsconfig.json`; with them on, the project measured
276 lib and 286 spec errors. Both configs are now at 0 with no CLI overrides.

The spec figure was mostly an echo: 280 of those 286 were the same production
sources pulled in through imports. Only six errors actually lived in spec
files, and five of them were one drifted fixture.

This last commit is the remaining components plus the small services, and the
flags themselves. Notable, beyond narrowing:

- `ActionService.updateRuleAction` and `ConditionService.save` both handled an
  unsaved model by calling their own create method and *discarding* the
  observable — nothing subscribed, so the POST never fired, and each then fell
  off the end and handed its caller `undefined` to subscribe to. Their sibling
  `ConditionGroupService.save` has always had the `return`. Now all three do.
- `_handle403Error` was declared `(e: CwError)` and opened by casting its own
  parameter to `HttpErrorResponse`. The seven `subscribe` error callbacks that
  feed it were annotated `CwError` too; at runtime they are all
  `HttpErrorResponse`. Replaced with a structural type naming the two fields
  the method actually reads.
- The `required` flag on text and date-time condition inputs came from
  `paramDef.inputType.dataType?.['minLength'] > 0`. `minLength` is a
  *constraint* on the data type, not a property of it, so that read has always
  been `undefined > 0` — false since it was written. Kept false deliberately,
  behind a named helper that explains why: reading the real constraint would
  start enforcing required on those fields, which is a UI change and wants its
  own issue.
- `isPersisted()` is now a `this`-typed predicate (`this is this & { key:
  string }`), so `if (model.isPersisted())` narrows `key` for the callers that
  go on to build a URL from it.
- The `patch*` methods in the container passed an unsaved rule's `null` key to
  services that interpolate it into a path or send it as `owningRule`. Those
  requests could only fail; they now short-circuit with a log line. Unreachable
  in practice — an action or group only has a key once its rule was saved — but
  the code no longer pretends otherwise.
- `patchCondition` had the same eight-line "add condition and record its key"
  block twice, and the copy inside the create-group callback read a key that
  the create had only just assigned to the captured model. Extracted, and it
  now reads the key off the create's own emitted value.
- `apiKey` on `DotVisitorsLocationContainerComponent` was declared, never
  assigned and never read. Gone.

Verified:

    tsc -p tsconfig.lib.json    0   (was 276)
    tsc -p tsconfig.spec.json   0   (was 286)
    nx run dot-rules:test       12/12, exit 0
    nx run dot-rules:lint       exit 0
    nx run dotcms-ui:build      exit 0

One limit worth stating: `dot-rules` has no `build` target, so `tsc -p` is its
only gate, and `tsc -p` does not check templates. The `dotcms-ui` build does
compile these sources — the chunk carrying `dot-rule-engine` is in `dist` — so
the templates bind cleanly, but that app sets `strictTemplates: false`
(#35930), so nothing checks these templates *strictly* yet. Neither dependent
(`dotcms-ui`, `edit-ema/portlet`) imports a single symbol from this library
beyond `DotRulesModule`, so widening its public types has no blast radius.

Closes #35957

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…tgrew (#35975)

`libs/portlets/edit-ema/portlet` has only `lint` and `test` targets, and
`test` is transpile-only, so nothing has type-checked this library. Under its
*current* tsconfig — four of the six strict flags, `strict` and
`noPropertyAccessFromIndexSignature` still off — it reported 188 lib and 22
spec errors. All of it pre-existing. Both configs are now at 0, before any
strict flag is added.

The lib figure was almost entirely two config defects:

`tsconfig.lib.json` compiled `src/lib/shared/mocks.ts` as a production source.
It is 1061 lines of test fixtures, imported by 18 spec files and no production
file, not exported from `src/index.ts`, and reachable by nothing outside this
project — but its name does not end in `.spec.ts`, so the exclude globs never
caught it. It pulls in `@dotcms/utils-testing`, which has no jest globals under
this config's `types: []`: 29 of the reported errors came from there. That is
the fourth instance of this defect class in the epic, after the two in the
previous commit.

The other 7 were `src/lib/store/features/editor/save/withSave.ts`, which does
not compile: it imports `../../../../services/dot-page-api.service` (the
directory is `dot-page-api/`) and `../../load/withLoad`, which does not exist
anywhere in the repo. Nothing imports `withSave` — the only reference is a
comment in `withPageApi.ts` reading "This feature consolidates withLoad and
withSave for better organization", and `withPageApi` does carry `save`,
`saveStyleEditor` and the rest. It is a leftover from that consolidation that
was never deleted, and it has been broken since. Deleted.

On the spec side, six specs imported `StyleEditorFieldSchema`,
`StyleEditorRadioOptionObject` and `StyleEditorFormSchema` from
`@dotcms/uve`, which does not export them — they live in
`@dotcms/types/internal`, which is where the components under test already
import them from. Pointed the specs at the same place.

The remaining 14: eleven reads of `protected` component members, moved to the
bracket access this repo already uses for the same purpose, and one local
`workflowActionMock` whose `actionInputs[].body` was `[]` where
`DotCMSWorkflowInput.body` is a `Record<string, unknown>`. The tests pass that
value straight through and assert it comes back, so `{}` says the same thing.

    tsconfig.lib.json    188 → 0
    tsconfig.spec.json    22 → 0

Tests 1397 passed / 5 skipped across 64 suites, lint clean. The two missing
strict flags come next, on an honest baseline.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…methods (#35975)

`withEditor` declared
`props: type<PageComputed & WorkflowLockComputed & ViewComputed>()` — three
whole interfaces, of which it reads four signals: `pageAsset`,
`pageVariantId`, `viewMode` and `$lockIsPageLocked`.

That constraint silently degraded the *host* store's type. `signalStore`
resolved `UVEStore` as `{ [x: string]: Function; uveStatus: Signal<...>; ... }`
— every method collapsed into a string index signature, while the signals
stayed named. Nothing failed, because the index signature accepts the calls;
the damage only becomes visible under `noPropertyAccessFromIndexSignature`,
where 43 ordinary calls like `uveStore.pageReload()` turn into TS4111. It is
also the reason `withWorkflow` reaches `pageReload()` through a type assertion,
which the store's own composition comment records.

Bisected to `WorkflowLockComputed` specifically: dropping the constraint
entirely resolves the store cleanly, and so does `props: type<PageComputed>()`
or `props: type<ViewComputed>()` — the same two interfaces `withWorkflow` and
`withView` already use this way without trouble. Naming the intersection as a
single interface does not help either, so it is the content, not the syntax.
Narrowing to what is actually consumed is what fixes it.

    tsconfig.lib.json with --strict --noPropertyAccessFromIndexSignature
      321 → 277 errors, of which TS4111 73 → 30

Type-only: the same 64 suites and 1397 tests pass, and both configs stay at 0
under the project's current flags.

While here: `PageSnapshot` was used in this file and never imported. It landed
during this change, but the class of problem is worth noting — an unresolved
type name makes the annotation `any`, so the three errors it was hiding only
appeared once the import was added.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ything (#35975)

`DotUveActionsHandlerService` declared its dispatch table as
`Record<DotCMSUVEAction, (payload: unknown) => void>` while thirteen of its
nineteen handlers take a specific payload. `strictFunctionTypes` rejects
assigning `(p: SetUrlPayload) => void` to `(p: unknown) => void`, and it is
right to — the map was asserting the opposite of what the handlers accept.

Replaced with a `UveActionPayloads` interface pairing each action with the
payload it actually carries, and a mapped `UveActionHandlers` type over it, so
each handler keeps its own parameter type. The six handlers that take no
payload need no entry of their own: a function may ignore arguments it is
passed. That leaves exactly one cast, at the dispatch site, which is where it
belongs — `action` and `payload` arrive from the SDK as an unrelated pair, so
nothing in this file can prove they match, and indexing the map yields the
union of every handler, which accepts only the intersection of their payloads.

The 30 remaining `TS4111` are ordinary index-signature reads — route `data`
and `params`, `dataset` (`DOMStringMap`), and `Record`-typed contentlet
fields — converted to bracket access. Done from the compiler's own
file/line/column output, verifying the property name sits at the reported
position and rewriting rightmost-first per line, with a check afterwards that
no nested or doubled brackets were produced.

    tsconfig.lib.json with --strict --noPropertyAccessFromIndexSignature
      277 → 234   (TS2418 13 → 0, TS4111 30 → 0)

64 suites, 1397 tests, lint clean; both configs still 0 under the project's
current flags.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ee (#35975)

Three destructurings of values that can be absent, and ten fields declared
without an initialiser.

`$requestWithParams` in `withPage` guarded `requestMetadata()` and then re-read
it twice after the guard, which narrowing does not survive; `pageParams()` had
no guard at all, though a request can be in flight before the params land and
there are no variables to send without them. Both now read into locals and are
guarded once.

`toggleLock` destructured `$lockOptions()`, which is nullable. The template
only renders that button inside `@if ($lockOptions()?.canLock)`, so the guard
is a formality — but it is the honest way to say the options may be absent.

`DotEmaDialogComponent.dialogState` came from `toSignal(this.store.dialogState$)`,
i.e. `EditEmaDialogState | undefined`, and three call sites read through it
directly. `dialogState$` is a ComponentStore selector, which emits
synchronously on subscribe — that was already the assumption, so it now says
so with `requireSync: true`, which throws at construction if it ever stops
being true rather than surfacing as an undefined property downstream.

The ten `TS2564` are `@ViewChild` and `@Input` fields Angular assigns, taking
the `!` this codebase already uses for exactly those (`iframeComponent!` sat
two lines from three that lacked it), plus two where absence is a real state:
`favoritePage` is `contentlets[0]` of a possibly-empty list, which is what the
sibling `bookmarked` signal reflects, and `lastTemplate` is unset until the
user edits the layout.

That last one had a test relying on the defect. `initForceSaveOnLeave` called
`saveTemplate(this.lastTemplate)` with no guard, so leaving the page without
touching the layout passed `undefined` to a parameter typed
`DotTemplateDesigner` and on to the layout save API. Guarding it broke
"should save right away if we request page leave before the 5 secs", because
all five tests in that block called `templateBuilder.templateChange.emit()`
with no argument — `EventEmitter.emit()` takes an optional parameter, so it
compiled, and `lastTemplate` became `undefined`. The real
`TemplateBuilderComponent` always emits a designer object. Fixed the spec to
emit one rather than relax the guard; no assertion changed, and all five still
pass.

    tsconfig.lib.json with --strict --noPropertyAccessFromIndexSignature
      234 → 213

64 suites, 1397 tests, lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…stated (#35975)

`lib/utils/index.ts` went from 22 strict-mode errors to 0, and most of them
traced to two preconditions the payload types did not express.

`insertContentletInContainer` needs the id of the contentlet it is writing.
`newContentletId` is optional on `ActionPayload` because most payloads describe
a position rather than a write — but every caller of the insert already
supplies it, and without one `undefined` reached `contentletsId.push()` and
from there the save request. Now `InsertActionPayload`.

`deleteContentletFromContainer` needs the contentlet it is removing; it filters
the container's ids by `contentlet.identifier`. `ClientData.contentlet` is
optional because a drop onto an empty container has none, so this used to throw
a `TypeError` on that path. Now `ContentletActionPayload`, and of its two call
sites one proves it by construction — `createDeletePayload` builds the
contentlet — while the other guards, because there the payload arrives through
the SDK's bounds message where the field really is optional.

Also in that file:

- `insertPositionedContentletInContainer` looked up its insertion point with
  `indexOf(contentlet.identifier)`. With no pivot that was `indexOf(undefined)`
  → -1 → fall through to append. Same behaviour, but it now says "no pivot
  means append" instead of relying on that.
- `removeUndefinedValues` was declared to take `DotPageAssetParams`, which
  neither of its two callers passes. It is a generic strip-undefined helper and
  is now typed as one.
- `getDragItemData` read `type`/`item` off a `DOMStringMap` and then
  `contentType.baseType` / `contentlet.contentType`, all three optional. A
  malformed dataset already ended in the `catch` that returns null; these paths
  now reach the same conclusion without the throw.
- `mapContainerStructureToDotContainerMap` is where the SDK's `DotCMSContainer`
  meets the legacy `DotContainer`. They differ in exactly one field — `source`,
  `string` versus the `CONTAINER_SOURCE` enum — so the cast is documented at
  that one boundary rather than spread over the map.

A note on the numbers, because they do not move monotonically: typing the two
implicitly-`any` parameters (`normalizeQueryParams`, `convertClientParamsToPageParams`)
took the total from 213 to 239 before the rest brought it to 194. Those 26 were
real errors their callers had been hiding behind `any`, 17 of them
index-signature reads. A count that rises when an `any` is removed is the
honest measurement.

    tsconfig.lib.json with --strict --noPropertyAccessFromIndexSignature
      213 → 194
    tsconfig.lib.json / tsconfig.spec.json under the project's current flags
      0 / 0, unchanged

64 suites, 1397 tests, lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Three files conflicted. `main` had added a whole new Experiments portlet, which
is why GitHub listed many more — git resolved the rest on its own.

- `edit-content/.../dot-edit-content-field.constant.ts` — both sides kept.
  `main` already carries `1995adcfac refactor(dotcms-models): enable TypeScript
  strict mode #35934`, an earlier project of this same epic merged separately,
  which turned `ComponentStatus` from an `enum` into an `as const` object. So
  the key had to become `typeof ComponentStatus.ERROR`, from `main`, while the
  value keeps this branch's `PrincipalConfiguration & { subtitle: string }`.
- `dot-experiments-list.component.ts` — took `main`. It removed the
  create-sidebar mechanism from that component, leaving the `componentRef`
  field with no users.
- `sdk/vue/.../DotImage.vue` — took `main`, which wraps the image in an anchor
  (#36998). This branch differed only in indentation.

What the merge cost, since `main`'s new code was written without the flags this
branch turns on. Four projects that were at 0 had to be brought back:

- `dot-experiments` — `main` moved the old list component under `old/`. Git put
  this branch's `!` on the new path and the `old/` copy arrived without it.
- `dot-experiments` — a new spec passes `Partial<C>` where Spectator's `props`
  wants `InferInputSignals<C>`; same cast the sibling specs here already use.
- `content-drive` — four new mocks omit `_body`, which
  `DotAjaxActionResponseView` declares, and one loop widened three literal ids
  with `as string[]` where the `Map` is keyed by
  `DotActionCenterQuickActionId`. `as const` is the fix: the ids were already
  literals, but a mutable array literal widens its elements.
- `dot-analytics` — `status = ComponentStatus.LOADED` now infers the literal
  `'LOADED'`, so the tests that set LOADING and ERROR needed the field
  annotated with the union.

Verified by measuring the same configs in a throwaway worktree at plain
`origin/main`, to separate this branch's work from what was already broken:

                              origin/main    this branch
    dot-agents lib                   634              2
    dot-analytics spec                19              0
    sdk/react spec                     7              7
    libs/dotcms lib / spec        17 / 36        17 / 36

Nothing regressed. The counts that stayed put are the documented measurement
traps — `virtual:sdk-version` in the three SDK consumers, `TS2688` on the
missing `@types/jasmine` in `dotcms-js`, and `libs/dotcms`, which no epic issue
covers yet.

Every project this branch has closed is back at 0 on both configs, including
`edit-ema/portlet` and `dot-rules`. Tests green across `dot-rules`,
`edit-content`, `dot-experiments`, `content-drive` and `dot-analytics`:
3805 passing, 2 skipped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…e wrong value (#35975)

`withPageApi.ts` goes from 15 strict-mode errors to 0. Most of them came from
one block repeated four times:

    const pageRequest = !deps.requestMetadata()
        ? dotPageApiService.get(store.pageParams())
        : dotPageApiService.getGraphQLPage(deps.$requestWithParams())

Each copy tests `requestMetadata()` and then passes `$requestWithParams()` —
two different nullable reads, which the compiler cannot correlate. Branching on
the value that is actually used is the same decision, because
`$requestWithParams` returns null exactly when there is no request metadata,
and it is the one narrowing can follow. `store.pageParams()` gets the same
treatment, with an `EMPTY` for the case where neither identifies a page; that
request could only have failed.

Deliberately not extracted into a helper. It should be — the duplication is the
real problem — but this is the portlet's load and save path and this is a typing
pass. Noted in a comment at the first site.

`dotPageLayoutService.save` read `page.identifier` with no check that a page had
loaded, and `DotTemplateDesigner.title` was `string | undefined` while three
call sites deliberately send `title: null`, which is how the layout endpoint
distinguishes "save this as a page layout" from "save it as a named template".
Widened the model; blast radius measured across seven strict projects, zero.

I got the guard for that save wrong first, and two tests caught it. I had
written `!template?.theme`, reading an empty theme as a missing one.
`mockDotTemplate()` does not omit `theme` — it sets `theme: ''`, and
`DotCMSTemplate.theme` is a required `string` whose empty value is what a page
whose template has no theme assigned actually carries. The guard refused to save
those pages' layouts, where the old code sent `themeId: ''` through. What made
`theme` read as `string | undefined` was never the field; it was the `?.` on
`pageAsset()`. Three separate optional reads of one asset narrow none of them,
so the asset is now read once and guarded once — `page`, `layout` and `template`
are all required on `DotCMSPageAsset` — and the empty theme travels as before.

    tsconfig.lib.json with --strict --noPropertyAccessFromIndexSignature
      174 → 157
    tsconfig.lib.json / tsconfig.spec.json under the project's current flags
      0 / 0

64 suites, 1397 tests, lint clean on this project and on dotcms-models.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ype that rejects it (#35975)

`withEditor.ts` goes from 13 strict-mode errors to 0.

`[RUNNING, SCHEDULED].includes(experiment?.status)` appeared inline in three
places — `computeCanEditPage` in utils and twice here. `includes` rejects an
optional status, correctly: "no experiment" is not "a blocking experiment".
Extracted as `isExperimentBlockingEdit`.

Three signatures that were wrong rather than merely strict:

- `buildIframeURL({ url, params, dotCMSHost })` had no parameter type at all,
  so all three destructured names were implicitly `any`. Typed with
  `DotPageAssetParams`, which is what `getFullPageURL` already requires of the
  same value.
- `getPersonalization(persona: DotCMSViewAsPersona)` declared its parameter
  required while the first branch of its body is the "no persona" case, and its
  caller passes `viewAs?.persona`.
- `PageData` declared `id`, `languageId` and `personaTag` required, but it is
  derived from `pageAsset()`, which is null until a page loads.

Two judgement calls worth flagging:

`getPageSavePayload` built its container as
`positionPayload.container ? { ...container, contentletsId } : null`. `container`
is required on `PositionPayload`, and an `ActionPayload` without one is not
constructible, so that null branch was guarding against a shape the parameter
type rules out. Removed.

The `?? ''` fallbacks in `getPageSavePayload` and `getCurrentTreeNode` I am less
happy with. Both read the now-optional `PageData` fields, both are reached only
from SDK messages that a rendered page produces, and both replace an
`undefined.toString()` that is what happened before if they ever were reached.
A guard would be better, but both methods return non-optional types
(`ActionPayload`, `DotTreeNode`) and there is no honest value to return without
a page. Left as a fallback with the reasoning in a comment; an explicit throw
would be a defensible alternative.

Also: `numberContents > 1` on an optional count (`undefined > 1` and `0 > 1`
agree, so `?? 0` preserves it), `$styleSchema` declared `StyleEditorFormSchema`
while its `find` can miss and its consumer already expects `| undefined`,
`$pageRender` declared `string` over an optional `rendered`, and
`getCurrentTreeNode` called `findIndex` on `contentletsId`, which is optional
because a container the SDK reports before any content has been added has none.

    tsconfig.lib.json with --strict --noPropertyAccessFromIndexSignature
      157 → 144
    tsconfig.lib.json / tsconfig.spec.json under the project's current flags
      0 / 0

64 suites, 1397 tests, lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…nnel (#35975)

`edit-ema-editor.component.ts` goes from 21 strict-mode errors to 0. Two of them
were real defects in the file-drop path.

`DotTempFileUploadService.upload` is typed
`Observable<DotCMSTempFile[] | string>`, and that union is not sloppiness: its
`handleError` does `map((err) => err.status.toString())`, so a failed upload
emits the HTTP status as a *string* on the success channel. The caller here
destructured every emission as `DotCMSTempFile[]`. On the string arm that took
the string's first *character*, read `image` off it as undefined, and fell into
the "not an image" branch — the right message, by accident. Now it checks.

I started writing an overload on the service instead (`File` →
`DotCMSTempFile[]`, `string` → `string`) and stopped: it would have been wrong.
The string arm is the error path and is reachable for both input forms.

`handleFileUpload` takes the drag item from `editorDragItem()`, which only a
palette drag sets. A file dragged straight from the desktop arrives with null,
and at the end of the pipe `placeItem(payload, null)` reads
`dragItem.draggedPayload` — a `TypeError`. Guarded: the asset is still uploaded
and published, only the placement is skipped. That needs its own issue; the
intended behaviour for a desktop file drop is not something I can infer from
here.

The rest were signatures describing less than their bodies handle.
`isSamePageNavigation` and `getTargetUrl` declared required parameters whose
first lines are the absent case. `DialogAction.actionPayload` is optional — the
model documents that it is missing when the dialog is opened outside a page
asset — and four handlers dereferenced it; they now return early, which is the
only thing they could do without a container to insert into.
`searchParams.get()` returns null for an absent parameter, which `pageLoad` was
reading as a language rather than as "keep the current one".

Also removed a `? : null` on the move path's container and a redundant
`canReinsertRelative` flag I had introduced a moment earlier: the guard now
checks the three things a move actually needs — origin container, pivot
contentlet, insert position — in one place.

    tsconfig.lib.json with --strict --noPropertyAccessFromIndexSignature
      144 → 119
    tsconfig.lib.json / tsconfig.spec.json under the project's current flags
      0 / 0

64 suites, 1397 tests, lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>